ALB 생성 및 연결

목표

Application Load Balancer를 생성하고 Target Group과 연결해서 실제로 동작하게 만들기

ALB 생성

1단계: Load Balancer 생성 시작

1. EC2 콘솔 → 왼쪽 메뉴 로드 밸런서 클릭
2. 로드 밸런서 생성 버튼 클릭
3. Application Load Balancer 선택 → 생성 클릭

2단계: 기본 구성

Load Balancer 이름:

• webapp-alb

체계:

• 인터넷 경계 선택 (외부에서 접근 가능)

IP 주소 유형:

• IPv4 선택

3단계: 네트워크 매핑

VPC:

• 여러분의 VPC 선택 (예: webapp-vpc)

매핑:

• ap-northeast-2a: 기존 Public 서브넷 선택
• ap-northeast-2c: webapp-public-subnet-2c 선택

4단계: 보안 그룹

보안 그룹:

• 기존 Web 서버용 보안 그룹 선택
• 또는 새로 만들기:
  • 이름: webapp-alb-sg
  • 인바운드: HTTP (포트 80) - 소스: 0.0.0.0/0
  • 인바운드: HTTPS (포트 443) - 소스: 0.0.0.0/0 (나중을 위해)

5단계: 리스너 및 라우팅

리스너:

• 프로토콜: HTTP
• 포트: 80

기본 작업:

• 대상 그룹으로 전달 선택
• 대상 그룹: webapp-web-targets 선택

6단계: Load Balancer 생성

로드 밸런서 생성 클릭

생성 대기

ALB 생성에는 2-3분 정도 걸립니다.

상태 확인:

• 프로비저닝 중 → 활성 상태로 변경될 때까지 대기

동작 확인

ALB DNS 이름 확인

1. 로드 밸런서 목록에서 webapp-alb 클릭
2. 세부 정보에서 DNS 이름 복사
   • 예시: webapp-alb-123456789.ap-northeast-2.elb.amazonaws.com

브라우저 테스트

ALB를 통한 접속:

정적 파일 테스트:

http://webapp-alb-123456789.ap-northeast-2.elb.amazonaws.com/webapp/index.html

동적 파일 테스트:

http://webapp-alb-123456789.ap-northeast-2.elb.amazonaws.com/webapp/

직접 서버 접속과 비교:

직접 접속: http://EC2-Public-IP/webapp/
ALB 접속: http://ALB-DNS-Name/webapp/

둘 다 같은 페이지가 나와야 함

동작 원리 확인

트래픽 흐름

사용자 → ALB → Target Group → Web 서버 → WAS 서버 → RDS

Health Check 동작

1. 대상 그룹 → webapp-web-targets 클릭
2. 대상 탭에서 상태 확인
3. healthy 상태인 서버에만 트래픽 전달

고급 테스트

여러 번 새로고침 테스트

현재는 서버가 1대뿐이라 차이가 없지만, 나중에 서버 2대가 되면 다른 서버로 요청이 분산됩니다.

응답 시간 비교

# 직접 접속 시간 측정
time curl -s http://Web서버-Public-IP/webapp/ > /dev/null

# ALB 접속 시간 측정  
time curl -s http://ALB-DNS-Name/webapp/ > /dev/null

# ALB를 거쳐도 비슷한 응답 시간이어야 함

로그 확인

Web 서버에서 접근 로그 확인:

ssh -i webapp-keypair.pem ec2-user@Web서버-Public-IP

# Apache 로그에서 ALB 요청 확인
sudo tail -f /var/log/httpd/access_log

# ALB의 IP 주소에서 오는 요청들 확인 가능

문제 해결

ALB 접속이 안 될 때

1. ALB 상태 확인:

• 상태가 활성인지 확인
• 프로비저닝 완료될 때까지 대기

2. 보안 그룹 확인:

• ALB 보안 그룹에 포트 80이 열려있는지 확인
• 소스가 0.0.0.0/0으로 설정되어 있는지 확인

3. Target Group 확인:

• 대상 인스턴스가 healthy 상태인지 확인
• Health Check 경로가 올바른지 확인

4. 서브넷 확인:

• ALB가 올바른 Public 서브넷에 배치되었는지 확인
• 두 가용영역 모두 선택되었는지 확인

DNS 이름이 길어서 기억하기 어려울 때

나중에 Route 53으로 도메인 연결하거나, 지금은 북마크 저장하세요.

ALB 활용 팁

포트 흐름 이해

사용자 → ALB:80 → Target Group:80 → 서버:80

모든 구간이 HTTP 포트 80으로 통일

다중 서브넷 배치의 이유

ALB가 2개 가용영역에 배치된 이유:

• 한 가용영역 고장나도 ALB 자체는 살아있음
• 고가용성 보장

비용 최적화

• ALB는 시간당 과금 + 데이터 처리량 과금
• 실습 후 바로 삭제하면 비용 절약

Health Check 상세 분석

ALB Health Check vs 직접 접속

ALB Health Check가 하는 일:

30초마다 실행:
GET http://Web서버IP:80/webapp/

응답 확인:
- HTTP 200 응답 코드
- 응답 시간 5초 이내
- JSP 페이지 정상 렌더링

실제 사용자 요청 흐름:

사용자 → ALB → Web서버 → WAS서버 → RDS → 응답

Health Check 로그 확인

# Web 서버 접근 로그에서 Health Check 요청 확인
sudo grep "GET /webapp/" /var/log/httpd/access_log | tail -5

# ALB IP에서 오는 정기적인 요청들이 보임

완료 체크리스트

• webapp-alb ALB 생성됨
• 상태가 활성으로 변경됨
• 2개 가용영역(2a, 2c)에 배치됨
• webapp-web-targets Target Group과 연결됨
• ALB DNS 이름으로 정적 파일 접속 성공
• ALB DNS 이름으로 동적 파일 접속 성공
• 직접 접속과 ALB 접속 결과가 동일함
• Target Group에서 서버 상태가 healthy임

중요 정보 기록

ALB 정보:

• 이름: webapp-alb
• DNS 이름: webapp-alb-xxxxxxx.ap-northeast-2.elb.amazonaws.com
• 리스너: HTTP 포트 80
• 타겟: webapp-web-targets
• 배치: 2개 가용영역 (2a, 2c)

이제 ALB를 통해서만 접속하세요:

• 기존: http://EC2-Public-IP/webapp/
• 신규: http://ALB-DNS-Name/webapp/

ALB 생성 완료 이제 Auto Scaling으로 서버를 자동 확장해봅시다.

다음 단계: AWS EDU/Archive/조선대학교 AWS 멘토링/Week3.5-HA-Scalable-WebService/03-Auto-Scaling-Group/01-Auto-Scaling개념

관련 문서: AWS EDU/Archive/조선대학교 AWS 멘토링/Week3.5-HA-Scalable-WebService/02-Application-Load-Balancer/02-Target-Group생성, AWS EDU/Archive/조선대학교 AWS 멘토링/Edu Architecture/README